fix(p2p): cap broadcast goroutines with bounded semaphore#775
fix(p2p): cap broadcast goroutines with bounded semaphore#775ordishs wants to merge 1 commit intobsv-blockchain:mainfrom
Conversation
|
🤖 Claude Code Review Status: Complete Summary: The implementation is solid and addresses the OOM issue effectively. The semaphore pattern correctly caps in-flight goroutines, and the test verifies the behavior with appropriate timing assertions. Observations: Minor - Test timing flexibility: The test uses a 2-second buffer for expectedMax (line 687 in test file). On slow CI runners or under heavy load, this might occasionally fail. Consider increasing the buffer or adding a note if flakiness occurs. Positive highlights:
|
|
Benchmark Comparison ReportBaseline: Current: Summary
All benchmark results (sec/op)
Threshold: >10% with p < 0.05 | Generated: 2026-04-28 20:23 UTC |



Closes #4574.
Summary
clientChannelMap.broadcastspawned one goroutine per client per message with no concurrency cap. Under a notification burst with many clients (256 clients × 100 msg/sec ≈ 25,600 goroutines/sec, plus per-goroutine timers), the resource pressure can OOM the node.Fix
Adds a fixed-size
chan struct{}semaphore (default 256 slots) that caps in-flight broadcast goroutines. The send-with-timeout logic inside each goroutine is unchanged.Test plan
(N / poolSize) * timeoutrather than the un-boundedtimeout(proves the semaphore actually serialises).go test -race ./services/p2p/...passes.